Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-219.txt

Text File | 1994-12-08 | 62.6 KB | 1,614 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 29 Nov 92       Volume 1 : Issue 219

Today's Topics:

    Memory Manager-safe Deferred Tasks - A Proposal
    How to tell if App is in Background?
    Newton Development
    Watch out for QDError
    MPW C++ 3.1, does it work with MPW 3.2??
    PBResolveFileIDRef() trouble
    Help! CTB's NuLookup() call crashing...



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  You can post articles to any newsgroup by
mailing your article to [e-mail].  So, to post an
article to comp.sys.mac.programmer, you mail it to
[e-mail].  Note the '-' instead of '.'
in the newsgroup name.

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Jeff E Mandel)
Subject: Memory Manager-safe Deferred Tasks - A Proposal
Date: 12 Oct 92 15:37:01 GMT
Organization: Tulane University School of Medicine

I was mulling over the recent thread on asynchronous MacTCP calls, and it
finally became clear to me what it was I wanted as a "real-time mac
programmer" - an oxymoron, to be sure.

Basically, I like the concept of the Deferred Task manager, but the only
thing it really gets me is the ability to do something in a small number
of milliseconds after an interrupt without making the cursor jump around
and other interrupt-driven code halt in its tracks. What I really want is
the ability to take the data I've gotten from the interrupting device and
stuff it into a pointer or handle at the soonest opportunity. Thus, what
I want is the ability to place a task in the DT queue, but flag it as
"don't call me until you can give me access to the specified heap".
Something like:

FUNCTION DTHzInstall (dtTaskPtr: QElemPtr, dtHeapZone: THz) : OSErr;

I looked in IM-VI (p28-30), and I noticed that there is a function
DeferUserFn, which is designed to defer an interrupt routine which might
cause a double page fault from occuring. What I want is different, but
conceptually similar. I have this task which I want to run, but which
isn't safe to run now, so Mr. Memory Manager, run it when next it can run.

Why does this help? Because currently, if I want to do anything that
requires using the memory manager, I'm using a private event queue, and
hoping that my application gets called often enough that my queue gets
serviced before it starts overwriting itself. Normally, this is no
problem, but what happens if I switch it to the background, and ask Word
to repaginate my 50 page document? Or if the Appleshare Server dies, and
Appleshare puts up a helpful Alert box to tell me this?

So my question is, would this meet people's needs? Are there other things
that are needed in a deferred task, or can everything else be forestalled
until the event loop? I'm not promising to implement this, or even to use
someone else's scheme that does this; I just want to get discussion (as
opposed to flames) going.

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andreas Wuertz)
Date: 13 Oct 92 16:05:13 GMT
Organization: Federal Institute of Technology

In article <[e-mail]> Jeff E Mandel,
[e-mail] writes:
>requires using the memory manager, I'm using a private event queue, and
>hoping that my application gets called often enough that my queue gets
>serviced before it starts overwriting itself. Normally, this is no

How about posting a HighLevel Event to your application?
PostHighLevelEvent may be called during irq/dt as far as I know.

Andy ([e-mail])

========================================================================
The only person who got all his work done by Friday was Robinson Crusoe.
========================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Jeff E Mandel)
Date: 13 Oct 92 19:57:07 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> Andreas Wuertz,
[e-mail] writes:
>How about posting a HighLevel Event to your application?
>PostHighLevelEvent may be called during irq/dt as far as I know.

It doesn't solve the problem. There is no way the HLE can get serviced
until I get back to the event loop, which could be milliseconds or hours,
depending on the friendliness of the foreground app and/or user. In any
event (heh, heh), once I'm in the event loop, it's no problem to do with
my own private event queue.

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Wed, 14 Oct 1992 04:44:55 GMT

Jeff E Mandel <[e-mail]> writes:

>Basically, I like the concept of the Deferred Task manager, but the only
>thing it really gets me is the ability to do something in a small number
>of milliseconds after an interrupt without making the cursor jump around
>and other interrupt-driven code halt in its tracks. What I really want is
>the ability to take the data I've gotten from the interrupting device and
>stuff it into a pointer or handle at the soonest opportunity. Thus, what
>I want is the ability to place a task in the DT queue, but flag it as
>"don't call me until you can give me access to the specified heap".

I like this idea very much, and this would actually be pretty easy to
implement: You could write a device driver that would simply call the
routine you specified. You could call the device driver asynchronously,
which can be done at interrupt time; the call will remain in the queue
until interrupt time is over and the system gets to call the driver.
Then the driver would call your task, which would be free to move
memory. This should happen at least somewhat quicker than having to
wait for your event loop to come around for the next time.

I do see one problem with the scheme:

>Something like:

>FUNCTION DTHzInstall (dtTaskPtr: QElemPtr, dtHeapZone: THz) : OSErr;

Note that the dtTaskPtr, or the parameter block in the case of my
device driver idea, would have to be preallocated. You would still run
into the same problem you have in your internal queue, that you may
run out of space; in this case, you might run out of the queue
elements you have allocated. But other than this, it would be no
problem.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: Jeff E Mandel <[e-mail]>
Organization: Tulane University School of Medicine
Date: Wed, 14 Oct 1992 14:11:51 GMT

In article <[e-mail]> Pete Resnick,
[e-mail] writes:
>I like this idea very much, and this would actually be pretty easy to
>implement: You could write a device driver that would simply call the
>routine you specified. You could call the device driver asynchronously,
>which can be done at interrupt time; the call will remain in the queue
>until interrupt time is over and the system gets to call the driver.
>Then the driver would call your task, which would be free to move
>memory. This should happen at least somewhat quicker than having to
>wait for your event loop to come around for the next time.

Well, I have done stuff like this in a driver, and you still have the
same problem - someone has to call SystemTask for the driver to get
called, and you can't always depend on it happening as often as you want.

>
>I do see one problem with the scheme:
>
>>Something like:
>
>>FUNCTION DTHzInstall (dtTaskPtr: QElemPtr, dtHeapZone: THz) : OSErr;
>
>Note that the dtTaskPtr, or the parameter block in the case of my
>device driver idea, would have to be preallocated. You would still run
>into the same problem you have in your internal queue, that you may
>run out of space; in this case, you might run out of the queue
>elements you have allocated. But other than this, it would be no
>problem.

There is no problem with preallocating enough dtTaskPtrs if you are
guaranteed that the time that the dtTask is pending is small. When it is
unbounded, then you need to make it BIG, which is why I strongly advocate
the private queue. If you use a standard system queue, such as the event
queue, you need to enlarge this queue's allocation at boot time, and it
is memory permanently committed to this function.

Since people don't seem to be jumping in on this, here's my thinking on
how to implement DTHzInstall.  It seems to me that the two problems to
avoid are reentering a Memory Manager call that is non-reentrant, and
attempting to move memory in a heap that is not "quiet". I'm pretty sure
that satisfying the first criterion also satisfies the second, but if it
doesn't, we can always solve that as well (why would you ever exit the
Memory Manager with an inconsistent heap?)

The problem is that of a critical section. Unless there is some secret,
undocumented semaphore for the Memory Manager, we create one of our own
by a head/tail patch for every Memory Manager routine. Basically, the
patch increments the semaphore on entry and decrements it on exit. Now,
when our dtTask is delivered, and the semaphore is nonzero, the task is
moved to a private queue, and the tail patch examines this queue, and
when the semaphore decrements to zero, it executes every task there. This
allows for the fact that one Memory Manager trap can invoke another. I'd
probably set the current heap to the one passed in the dtHeapZone
parameter and restore the previous one on exit.

The advantage of this approach is that you aren't messing with the memory
manager to try to make it reentrant, you're just getting your task
executed when the memory Manager isn't involved in managing memory. Sort
of the difference between "Sh*t or get off the pot!" and "Please let me
know when you're done, and if it's not too much trouble, leave me some
paper" :-).

OK, having spread the kerosene on the floor, let me retreat to my bunker
and wait for the flames to rise...

Jeff

+++++++++++++++++++++++++++

From: [e-mail] (Mark R. Valence)
Date: 14 Oct 92 13:33:59 GMT
Organization: Dartmouth College, Hanover, NH


Jeff E Mandel <[e-mail]> writes:
>
> [ suggestion for a Deferred Task Manager that allows memory movement. ]
>

In article <[e-mail]>
[e-mail] (Pete Resnick) writes:
> I like this idea very much, and this would actually be pretty easy to
> implement: You could write a device driver that would simply call the
> routine you specified. You could call the device driver asynchronously,
> which can be done at interrupt time; the call will remain in the queue
> until interrupt time is over and the system gets to call the driver.
> Then the driver would call your task, which would be free to move
> memory. This should happen at least somewhat quicker than having to
> wait for your event loop to come around for the next time.
>
> [ stuff deleted ]
>
> Note that the dtTaskPtr, or the parameter block in the case of my
> device driver idea, would have to be preallocated. You would still run
> into the same problem you have in your internal queue, that you may
> run out of space; in this case, you might run out of the queue
> elements you have allocated. But other than this, it would be no
> problem.

Well, just one more problem.  The device driver scheme suffers from the
same limitations that the previously mentioned PostHighLevelEvent
scheme does.  Time is only given to device drivers when nothing else is
happening on earlier systems (6.0.x and previous).  The newer System 7
gives drivers needTime on a more regular basis.

For example, when some application posts an alert in System 6, drivers
do not get any time (dialog manager doesn't call SystemTask ??  I
haven't explored.)  Also, if the mouse is held down in a menu, control,
window title bar, etc. - same problem, no time for drivers.

The dialog problem goes away with System 7.  Menu, control, window
problem is still there (I just re-confirmed that.  Boy, it's tough to
keep an async connection when you are in the debugger!).

All this really means is that you can't depend on quick response.  This
has the effect that your queue may overflow, with the implications
mentioned by Pete Resnick.

There are some alternatives:

1)  pre-allocate a buffer for a large queue.  Pray that the response
will not be too bad.  After all, you only have to respond to a user.
If the user is scrolling through the News, or moving that game window
aside, does he care if your window gets updated right this second?

2)  in order to allow for a large queue, you have to pre-allocate a
large buffer.  Well, if you are going to allocate all this space
anyway, why not use the current Deferred Task mechanism, and just do
your own memory management in this pre-allocated chunk of memory.

3)  redesign your time-critical program to be interrupt-level.

It all depends on how quickly you need the event to be processed.


Now back to the regularly scheduled discussions on the price of 7.1


Mark.

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: Wed, 14 Oct 92 15:15:49 EST
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Pete Resnick) writes:
> Jeff E Mandel <[e-mail]> writes:
>
> >Basically, I like the concept of the Deferred Task manager, but the only
> >thing it really gets me is the ability to do something in a small number
> >of milliseconds after an interrupt without making the cursor jump around
> >and other interrupt-driven code halt in its tracks. What I really want is
> >the ability to take the data I've gotten from the interrupting device and
> >stuff it into a pointer or handle at the soonest opportunity. Thus, what
> >I want is the ability to place a task in the DT queue, but flag it as
> >"don't call me until you can give me access to the specified heap".
>
> I like this idea very much, and this would actually be pretty easy to
> implement: You could write a device driver that would simply call the

When we implemented MacTCP and MacNFS at citi.umich.edu, we were faced
with countless interrupt level memory problems. As I remember, this was
easily solved by creating and managing our own little heap for the
things that we needed.


tim endres - [e-mail]  -or- tbomb!time
ICE Engineering, Inc - 8840 Main St, Whitmore Lake, MI 48189
Phone [phone] - FAX [phone]
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Mark R. Valence)
Date: 14 Oct 92 22:04:13 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Jeff E Mandel) writes:

> Since people don't seem to be jumping in on this, here's my thinking on
> how to implement DTHzInstall.  It seems to me that the two problems to
> avoid are reentering a Memory Manager call that is non-reentrant, and
> attempting to move memory in a heap that is not "quiet". I'm pretty sure
> that satisfying the first criterion also satisfies the second, but if it
> doesn't, we can always solve that as well (why would you ever exit the
> Memory Manager with an inconsistent heap?)
>
> The problem is that of a critical section. Unless there is some secret,
> undocumented semaphore for the Memory Manager, we create one of our own
> by a head/tail patch for every Memory Manager routine. Basically, the


Why not just patch NewHandle?  Then you can be guaranteed that it is
safe to allocate memory, move the heap around, etc. because someone is
already doing it.  You need a flag to make sure you don't re-enter your
task scheduler, but that is easy.  What's more, you can implement the
"Hz" functionality you originally wanted.  Here it is:

NewHandle patch (note that it is a head patch):

 if not alreadyExecuting then
    alreadyExecuting = true
    if SYS bit is set then
       theheap = SysZone
    else
       theheap = TheZone

    scan the queued tasks, execute the
    ones where dtHeapZone = theheap (or dtHeapZone = nil)

    alreadyExecuting = false
 endif
 JumpTo(realNewHandle)

end patch

Remember to save ALL registers!  One note on this declaration:

> FUNCTION DTHzInstall (dtTaskPtr: QElemPtr, dtHeapZone: THz) : OSErr;

Why not declare the following, which gives an "easier" function
declaration:

 DTHzElemRec = record
   qLink: Ptr;               { standard queue field }
   qType: integer;           { standard queue field }
   dthzReserved: LongInt;    { for future enhancements :-) }
   dthzProc: ProcPtr;        { pointer to the proc to execute }
   dthzZone: THz             { the zone that this elem likes, nil for
all }
 end;

 FUNCTION DTHzInstall (dthzTask: DTHzElemPtr): OSErr;

The problem with this implementation is that you don't know whether
QuickDraw is in use, so you cannot draw to any ports.  But maybe all
you want to do is allocate memory.  In general, you shouldn't use
managers that are not re-entrant.  To use Quickdraw, you could
similarly patch SetPort, and thereby make the executed tasks
port-dependant.

Honey?  Do you smell smoke?

Mark.

+++++++++++++++++++++++++++

From: Jeff E Mandel <[e-mail]>
Organization: Tulane University School of Medicine
Date: Thu, 15 Oct 1992 14:14:37 GMT

In article <[e-mail]> Mark R.
Valence, [e-mail] writes:
>> The problem is that of a critical section. Unless there is some secret,
>> undocumented semaphore for the Memory Manager, we create one of our own
>> by a head/tail patch for every Memory Manager routine. Basically, the
>
>
>Why not just patch NewHandle?  Then you can be guaranteed that it is
>safe to allocate memory, move the heap around, etc. because someone is
>already doing it.  You need a flag to make sure you don't re-enter your
>task scheduler, but that is easy.  What's more, you can implement the
>"Hz" functionality you originally wanted.  Here it is:
>
>NewHandle patch (note that it is a head patch):
>
> if not alreadyExecuting then
>    alreadyExecuting = true
>    if SYS bit is set then
>       theheap = SysZone
>    else
>       theheap = TheZone
>
>    scan the queued tasks, execute the
>    ones where dtHeapZone = theheap (or dtHeapZone = nil)
>
>    alreadyExecuting = false
> endif
> JumpTo(realNewHandle)
>
>end patch
>
>Remember to save ALL registers!

I believe this is not the best solution. There are many traps which move
memory, and NewHandle is only one. To make this approach work, you'd have
to head patch every trap which can move memory. Even if you wanted to do
that much patching (Which is certainly feasible), you still have the
problem that you are depending on someone to call one of the
memory-moving traps before your deferred task is delivered. What if
you're waiting for an IO request to complete? Or in a long computational
loop? the deferred task is frozen out.

>One note on this declaration:
>
>> FUNCTION DTHzInstall (dtTaskPtr: QElemPtr, dtHeapZone: THz) : OSErr;
>
>Why not declare the following, which gives an "easier" function
>declaration:
>
> DTHzElemRec = record
>   qLink: Ptr;               { standard queue field }
>   qType: integer;           { standard queue field }
>   dthzReserved: LongInt;    { for future enhancements :-) }
>   dthzProc: ProcPtr;        { pointer to the proc to execute }
>   dthzZone: THz             { the zone that this elem likes, nil for
>all }
> end;
>
> FUNCTION DTHzInstall (dthzTask: DTHzElemPtr): OSErr;

Well, I did it that way so the dtTakPtr structure could be used. If you
do it the way you suggest, then you should add a field for dtParm, so the
user can pass in a pointer to globals or such. Really, however, I'd make
the DTHzElemRec look like a DTElemRec with some extra fields, as
DTHzInstall would just install a DTTask that invoked code to determiine
whether the DTHzTask could be delivered immediately, or needed to be
moved to the special queue to await the completion of the pending memory
operations. Thus:

 DTHzElemRec = record
   qLink: Ptr;               { standard queue field }
   qType: integer;           { standard queue field }
   dthzReserved: LongInt;    { for future enhancements :-) }
   dthzProc: ProcPtr;        { filled in by  DTHzInstall}
   dthzZone: THz             { the zone that this elem will utilize }
   dthzTask: dtElemRec  { the DTTask }
 end;

>
>The problem with this implementation is that you don't know whether
>QuickDraw is in use, so you cannot draw to any ports.  But maybe all
>you want to do is allocate memory.  In general, you shouldn't use
>managers that are not re-entrant.  To use Quickdraw, you could
>similarly patch SetPort, and thereby make the executed tasks
>port-dependant.

I believe that it is a bad idea to try to have too many things going on
in "real-time". Drawing can be deferred until the app gets back to the
event loop. The user can't deal with the new data in a background app
when the foreground app is busy, so why worry about getting it to the
screen? The only thing that can't wait is stuffing data from an external
device into memory that won't be depleted under any foreseeable
circumstance, and reinitiating the read operation.
>
>Honey?  Do you smell smoke?
I don't know, dear. But doesn't that door feel awfully warm?

Jeff

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 15 Oct 92 16:13:47 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jeff E Mandel) writes:

>Well, I have done stuff like this in a driver, and you still have the
>same problem - someone has to call SystemTask for the driver to get
>called, and you can't always depend on it happening as often as you want.


Set up a vbltask and call it every few ticks. Its not on any of the lists
that says it moves memory or cannot be called at interupt time. :-)





Matt
- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Mark R. Valence)
Date: 16 Oct 92 03:15:20 GMT
Organization: Dartmouth College, Hanover, NH

I wrote:
>Why not just patch NewHandle?  Then you can be guaranteed that it is
>safe to allocate memory, move the heap around, etc. because someone is
>already doing it.  You need a flag to make sure you don't re-enter your
>task scheduler, but that is easy.  What's more, you can implement the
>"Hz" functionality you originally wanted.  Here it is:
>

In article <[e-mail]>
[e-mail] (Jeff E Mandel) writes:

> I believe this is not the best solution. There are many traps which move
> memory, and NewHandle is only one. To make this approach work, you'd have
> to head patch every trap which can move memory. Even if you wanted to do
> that much patching (Which is certainly feasible), you still have the
> problem that you are depending on someone to call one of the
> memory-moving traps before your deferred task is delivered. What if
> you're waiting for an IO request to complete? Or in a long computational
> loop? the deferred task is frozen out.


No, you don't have to patch every trap that can move memory (jeez,
that's quite a few!).  When ANYONE, including the routines in ROM,
calls NewHandle, they are basically saying "I don't care if memory
moves."  So, just patch NewHandle, and you have the necessary
conditions for a DTHz Manager.  You are right that you would then be
relying on someone else to call NewHandle, but that is going to be a
drawback of any scheme.  Even if you trap every memory moving trap,
what if my app is in the middle of its save loop (repeatedly calling
_Write, which can't move memory).  Well, I guess you could check to see
if it was an ASYNC write, and only do your DTHz stuff if the call was
ASYNC.  Anyway, the point is that the NewHandle scheme will work pretty
well (oh, go ahead and augment it with patches on NewPtr and
NewTempHandle).  Remember that NewRgn, GetResource, etc. call
NewHandle.

One test:  do an atb on NewHandle in MacsBug, and then try to get
anything done.  Even pulling down a menu gets it (you have to move the
mouse, though, so that some call is made that eventually gets down to
calling NewHandle).  The hard one is moving a window.  I guess a trap
on _DiffRgn will get the job done in this case.  Kind of ad hoc, but
you aren't writing System software here (if you were you wouldn't have
to worry about these hacks).

Here's a new idea:  replace the A-trap interrupt, have your handy
"these traps move memory" table on hand, and then do the DTHz tasks
when appropriate.  It would have to be done right (for speed), but it
should work, after all you are in WAY before the OS, down to the bare
bones CPU.  Neat-o.

> >Honey?  Do you smell smoke?
> I don't know, dear. But doesn't that door feel awfully warm?

I've got the best asbestos suit available:  Long, specialized post that
only you and I read, all others do the 'K' thing.

Mark.

+++++++++++++++++++++++++++

From: [e-mail] (scott boyd)
Date: Wed, 21 Oct 1992 06:48:19 GMT
Organization: Apple Computer Inc.

In article <[e-mail]>,
[e-mail] (Mark R. Valence) wrote:
[loads of bizarre stuff deleted]

Patching NewHandle to get yourself some safe-to-allocate time
begs the question (and totally ignores what you might do to
performance of the overall system if you aren't careful).

Let's go back to basics.  What are you trying to accomplish?
What is so important that it has to happen more often than
driver tickle time?

scott
[e-mail]
macintosh system software

+++++++++++++++++++++++++++

From: [e-mail] (Jeff E Mandel)
Date: 21 Oct 92 16:02:36 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> scott boyd,
[e-mail] writes:
>Patching NewHandle to get yourself some safe-to-allocate time
>begs the question (and totally ignores what you might do to
>performance of the overall system if you aren't careful).
>
>Let's go back to basics.  What are you trying to accomplish?
>What is so important that it has to happen more often than
>driver tickle time?

Scott, as I started this, let me answer for Mark. Basically, the general
class of problem we're discussing is interrupt-driven code, such as
drivers, connection tools, etc. The idea was to create a new type of
task, such as the Deferred Task, which would be delivered "soon", but be
able to allocate memory, but not depend on the foreground app to be a
good sport to function.

To my way of thinking, if I'm writing a driver which gathers data from an
external device which won't stop sending just because the user has
decided to mouse down in a menu, then I must have a mechanism for
buffering data until my event-loop level code gets called again. I can
allocate as much or as little as I want, but I have allocated that
memory, and it is there whether I use it or not.

An alternate approach would be to queue a task to a memory-safe deferred
task queue, which will be delivered the next time the Memory Manager
isn't busy. Mark feels the easiest way is to service the queue whenever
NewHandle is called, as that is prima facie evidence that the Memory
Manager is open for new business. I have advocated patching the entire
memory manager to maintain a guarding semaphore, and emptying the queue
when the semaphore is zero (either because it is zero when the task is
queued, or because our patched memory manager decrements it to zero). His
scheme is probably less intrusive, mine guarantees faster delivery (the
worst case being the time it takes to compact a swapped-out heap).

I know that this opens a big can of worms, but I believe that the benefit
is that it permits the driver writer to simply queue an asynchronous read
using memory from a small static pool for the ioBuffer, have a completion
routine which queues the memory-safe deferred task, which copies the
input data to a handle from temporary memory, and places the handle in a
queue to be processed in the event loop. That way, the driver can buffer
"indefinitely", even if the foreground app has hung and is waiting for
the user to command-option-escape. You'll recall I've written real-time
controllers which are used in the OR, and I have to be able to process
new data every two seconds (come hell or high water), and the
driver-tickle just isn't that reliable.

OK, so now tell me why it isn't possible, can be done with existing
facilities, or is evil.

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Date: 21 Oct 92 16:12:41 GMT
Organization: University of Illinois at Urbana

[e-mail] (scott boyd) writes:

>Let's go back to basics.  What are you trying to accomplish?
>What is so important that it has to happen more often than
>driver tickle time?

Let's take the example I had in mind when I asked the original
question: Let's say I wanted to implement a UNIX-like socket using
MacTCP that could do a listen. The spec on listen is that it will
listen to a certain TCP port and allow up to a user-specified number
of connections. So, in MacTCP, that means TCPCreate a stream (about
16K of memory for the receive buffer) and put a TCPPassiveOpen on that
stream. As soon as one connection is made, I need another stream and
another passive open on the same TCP port. I can't do it in the
completion routine of the PassiveOpen because I have to allocate the
memory for the new stream buffer. I have two choices:

1. Pre-allocate enough memory for every connection that could come in
when the person calls listen(). Ick!

2. Wait until I get back to my main event loop and allocate another
block. There are certain applications where that time delay would be
unacceptable.

Now, would the time delay for a device driver to come around and do it
for me be unacceptable? Probably not. But just *probably*. If we had an
AllocateMemASAP routine that we could call from interrupt, it would be
alot nicer.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hamlin)
Date: 23 Oct 92 23:48:39 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (Matt Mora) writes:

>In article <[e-mail]> [e-mail] (Jeff E Mandel) writes:

>>Well, I have done stuff like this in a driver, and you still have the
>>same problem - someone has to call SystemTask for the driver to get
>>called, and you can't always depend on it happening as often as you want.


>Set up a vbltask and call it every few ticks. Its not on any of the lists
>that says it moves memory or cannot be called at interupt time. :-)

  That's what AppleTalk does...



- --
Brian M. Hamlin                          NOESIS Software Construction
[e-mail]                                     [phone]

- --
- --
Brian M. Hamlin                          NOESIS Software Construction
[e-mail]                                     [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Jeff E Mandel)
Date: 26 Oct 92 14:33:14 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> Brian Hamlin,
[e-mail] writes:
>>Set up a vbltask and call it every few ticks. Its not on any of the
lists
>>that says it moves memory or cannot be called at interupt time. :-)
>
>  That's what AppleTalk does...

This doesn't solve the problem, as you can't call the memory manager from
a VBLTask either.

+++++++++++++++++++++++++++

From: [e-mail] (Martin Minow)
Date: 27 Oct 92 18:22:20 GMT
Organization: Apple Computer Inc., Cupertino, CA


[e-mail] (scott boyd) writes:
>Let's go back to basics.  What are you trying to accomplish?

Much of this discussion reminds me of the aphorism: "if your only tool
is a hammer, everything looks like a nail." As has been stated, the Mac
Memory Manager is not re-entrant and cannot be called from interrupt
routines.

The best solution for drivers and similar interrupt-driven code that
must allocate memory dynamically will be, in my experience, based on
a private, carefully written, interrupt-safe memory allocator that
runs off of a private memory pool. Your driver will initialize the pool
when it is opened for the first time. If you want to be exceedingly
clever, you could probably write a background task that manages the
pool size by using the Mac Memory Manager to allocate and deallocate
chunks of memory in a "safe" manner. The intricacies of communicating
between the driver and allocation task will be left as a exercise
for the student.

Martin Minow
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jeff E Mandel)
Date: 27 Oct 92 20:04:28 GMT
Organization: Tulane University School of Medicine

In article <[e-mail]> Martin Minow, [e-mail] writes:
>The best solution for drivers and similar interrupt-driven code that
>must allocate memory dynamically will be, in my experience, based on
>a private, carefully written, interrupt-safe memory allocator that
>runs off of a private memory pool. Your driver will initialize the pool
>when it is opened for the first time. If you want to be exceedingly
>clever, you could probably write a background task that manages the
>pool size by using the Mac Memory Manager to allocate and deallocate
>chunks of memory in a "safe" manner. The intricacies of communicating
>between the driver and allocation task will be left as a exercise
>for the student.

First, I know I can manage my own interrupt-level heap, and can probably
implement some sort of workspace trimming and expansion routine, but it
is a lot of trouble, and commits memory resources inefficiently. What I
need is not a way to manage a finite list of queue elements available for
communication with the event loop, but rather, a way to buffer events for
as long as possible if the event loop is frozen out, without having to
dedicate excessive memory resources to the task. I know, memory is cheap,
and everyone should have 20 megs so they can allocate a meg to a driver
and not worry about it.

My solution (which I believe will work) to this is to create a task
queue, which is serviced immediately if the Memory Manager isn't in the
way, or as soon as it moves out of the way. From the application
programmer's perspective, it's simple. In the ioCompletion routine, queue
a task which takes the contents of the input buffer, and copy it to a
handle, stuff the handle in a queue element, and let the event loop
process the queue. If an ill-behaved program grabs the foreground for an
hour, no problem, as long as there are memory resources to suuport it,
you buffer and catch up when you get called again.

So, some specific questions:

1) If I call NewHandle from an interrupt, and no Memory Manager call is
being interrupted, do I cause any harm?

2) On exit from a Memory Manager trap, is the heap ever inconsistent
(other than as a result of an error)?

3) Are there any traps, other than the documented traps of the Memory
Manager, which move memory themselves (i.e. as a result of something
other than a NewHandle call)?

I know that this idea hasn't exactly caught fire with the group, but I
suspect it reflects the fact that very few people use the Deferred Task
Manager. On the other hand, in the VMS world, it is very common to use
ASTs, because there is a much shorter list of system services which you
can't use from an AST.

If anyone is interested in the problem, and has some C/C++ code that
patches anything in the memory manager from an extension/control panel,
I'll see if I can program something up.

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Date: 27 Oct 92 19:59:24 GMT
Organization: University of Illinois at Urbana

[e-mail] (Martin Minow) writes:

>[e-mail] (scott boyd) writes:
>>Let's go back to basics.  What are you trying to accomplish?

>Much of this discussion reminds me of the aphorism: "if your only tool
>is a hammer, everything looks like a nail." As has been stated, the Mac
>Memory Manager is not re-entrant and cannot be called from interrupt
>routines.

>The best solution for drivers and similar interrupt-driven code that
>must allocate memory dynamically will be, in my experience, based on
>a private, carefully written, interrupt-safe memory allocator that
>runs off of a private memory pool.

Again, this misses the point. The problem is not that you can't
allocate enough memory for all of your uses at initialization time and
then use that; of course, that's easy. The *problem* is that you don't
want to allocate a huge chunk of memory if you don't need it.
Especially for things like drivers, sure I could allocate 1M right out
of the system heap, and use it as my private memory pool, but that is
exactly what I *don't* want to do when for the most part I will only
be using 1K, but sometimes I might need some more. All this
accomplishes is using up memory that other applications might very
well need when I don't.

The perfect answer would be to let me allocate the memory I need at
interrupt; we have all decided that this is not possible. What we have
been looking for here is a compromise: allocate me the memory I need
as soon as you can. The private memory pool just doesn't address this
problem. If anything, that is exactly making "everything look like a
nail."

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Werner)
Date: 27 Oct 92 20:42:44 GMT
Organization: UC Berkeley School of Education

In article <[e-mail]>, Jeff E Mandel
  <[e-mail]> wrote:
> 1) If I call NewHandle from an interrupt, and no Memory Manager call is
> being interrupted, do I cause any harm?

YES.  Some code (probably including many toolbox traps) may have
dereferenced a handle into a pointer, and your NewHandle call might move
the block out from under the pointer.  At interrupt time, it really isn't
safe to do anything that might move memory.  Period.

> 3) Are there any traps, other than the documented traps of the Memory
> Manager, which move memory themselves (i.e. as a result of something
> other than a NewHandle call)?

Remember that MM traps other than NewHandle can move memory too.  NewPtr
and MoveHHi come to mind immediately, but I'm sure there are others.

- --
John Werner                         [e-mail]
UC Berkeley School of Education     510-642-9651

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: Tue, 27 Oct 1992 21:08:24 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, Jeff E Mandel
<[e-mail]> wrote:
>
> In article <[e-mail]> Martin Minow, [e-mail] writes:
> >The best solution for drivers and similar interrupt-driven code that
> >must allocate memory dynamically will be, in my experience, based on
> >a private, carefully written, interrupt-safe memory allocator that
> >runs off of a private memory pool. Your driver will initialize the pool
> >when it is opened for the first time. If you want to be exceedingly
> >clever, you could probably write a background task that manages the
> >pool size by using the Mac Memory Manager to allocate and deallocate
> >chunks of memory in a "safe" manner. The intricacies of communicating
> >between the driver and allocation task will be left as a exercise
> >for the student.
>
> My solution (which I believe will work) to this is to create a task
> queue, which is serviced immediately if the Memory Manager isn't in the
> way, or as soon as it moves out of the way. From the application
> programmer's perspective, it's simple. In the ioCompletion routine, queue
> a task which takes the contents of the input buffer, and copy it to a
> handle, stuff the handle in a queue element, and let the event loop
> process the queue. If an ill-behaved program grabs the foreground for an
> hour, no problem, as long as there are memory resources to suuport it,
> you buffer and catch up when you get called again.
>
> So, some specific questions:
>
> 1) If I call NewHandle from an interrupt, and no Memory Manager call is
> being interrupted, do I cause any harm?
>
> 2) On exit from a Memory Manager trap, is the heap ever inconsistent
> (other than as a result of an error)?
>
> 3) Are there any traps, other than the documented traps of the Memory
> Manager, which move memory themselves (i.e. as a result of something
> other than a NewHandle call)?

Unfortunately, I don't see any way to make this work, except for perhaps
in a private heap, in which case using your own memory management is
probably a better solution.  The real sticking point is, as I see it,
that virtually all Mac programs and the toolbox rely on memory not
moving or being purged except at well-defined times.  Here's a perfectly
innocuous piece of code:

    baseAddress = (**myPixMap).baseAddr;

And here's what it compiles to:

 (1)  MOVEA.L    $0008(A6),A0
 (2)  MOVEA.L    (A0),A0
 (3)  MOVE.L     (A0),D7

If your interrupt fires between instructions (2) and (3) and allocates
a handle (or moves the heap in any way), you will have invalidated the
pointer in A0, which is a pointer into an unlocked block.  This is only
the first example; hundreds of programs use pointers into unlocked
blocks for long stretches of code, as long as they know they do not
call any routines that might cause the movement of the block in
question.  As far as I can tell, there is no way to determine at time
X whether any such pointers exist.  Thus, the only time memory can
be allocated from any shared heap (application, system or process
manager) is when a call which might move that heap is called.  Thus,
as far as I can tell, your scheme is unworkable, unless it relies
upon only getting control at appropriate times or using a heap which
is unused by any other process.

Tim Dierks
MacDTS, but I geek with my knees

+++++++++++++++++++++++++++

From: Jeff E Mandel <[e-mail]>
Organization: Tulane University School of Medicine
Date: Wed, 28 Oct 1992 14:56:44 GMT

In article <werner-271092123531@128.32.157.31> John Werner,
[e-mail] writes:
>YES.  Some code (probably including many toolbox traps) may have
>dereferenced a handle into a pointer, and your NewHandle call might move
>the block out from under the pointer.

In article <[e-mail]> Tim Dierks,
[e-mail] writes:
>The real sticking point is, as I see it,
>that virtually all Mac programs and the toolbox rely on memory not
>moving or being purged except at well-defined times.
[...]
> Thus, the only time memory can
>be allocated from any shared heap (application, system or process
>manager) is when a call which might move that heap is called.

Well, obviously correct. Since there is no way to guard everything that
dereferences a handle, the idea of delivering the task immediately if the
semaphore is zero won't work. On the other hand, servicing the queue on
exit from (or entrance to) the memory manager should not create the
problem, because after a memory  manager call any dereferenced handle
should be presumed invalid.

Since memory manager calls are fairly ubiquitous, there are very few
operations that a foreground application might be involved in which would
freeze out the queue servicing for very long. One is a tight calculation
loop, for which I can see no recourse; the other is a synchronous read
operation, where you sit in a loop polling ioStatus. I suppose you could
patch PBRead, but it isn't a trivial patch. In any event, it may not be
worth worrying about. My experience is that synchronous reads either
complete, time out in a reasonble amount of time, or hang the machine.

To make life easier for the application programmer trying to size the
(small) static buffer that would be necessary to avoid losing data while
waiting for the queue to be serviced, the queue service routine could
keep track of the interval between calls and update a count (available by
Gestalt) which would be the longest delay in the queue servicing.

So, having amended the proposal to eliminate immediate delivery, does
anyone else see any problem with having a queue which is serviced when
the patched memory manager traps are called?

Jeff E Mandel MD MS
Associate Professor of Anesthesiology
Tulane University School of Medicine
New Orleans, LA

[e-mail]

---------------------------

From: [e-mail] (Jerome Chan)
Subject: How to tell if App is in Background?
Date: 24 Oct 92 14:38:36 GMT
Organization: The Tofu Society of Singapore

How do you tell if an App is in the background? I seem to recall that it is
possible to launch an application in the background under system 7.x.

- ---
 The Evil Tofu

+++++++++++++++++++++++++++

From: [e-mail] (Jon Wtte)
Date: 24 Oct 92 15:59:22 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Jerome Chan) writes:

   How do you tell if an App is in the background? I seem to recall that it is
   possible to launch an application in the background under system 7.x.

Well:

1) You could assume you're in front at launch, and listen in on
   the osEvents that come.

2) You could use GetFrontProcess and call SameProcess with the
   result of GetCurrentProcess.

3) Background-only apps never are in the front.

- --
 -- Jon W{tte, [e-mail], Mac Hacker Suedoise (not french speaking) --
  _/~|   Yellow
 / * \_  Shark                      (This signature has won the "Worst ASCII
 ~~~~\/  Software                    Logo of the Year" award)

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 26 Oct 92 00:38:09 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Jon Wtte) wrote:
>
> > [e-mail] (Jerome Chan) writes:
>
>    How do you tell if an App is in the background? I seem to recall that it is
>    possible to launch an application in the background under system 7.x.
>
> Well:
>
> 1) You could assume you're in front at launch, and listen in on
>    the osEvents that come.
>
> 2) You could use GetFrontProcess and call SameProcess with the
>    result of GetCurrentProcess.
>
> 3) Background-only apps never are in the front.

Re 1): I think that all applications are initially launched into the
background, and that you should look for "resume" events before acting like
you are in the foreground. This is related to the "call WaitNextEvent three
times" trick before showing your application's splash screen.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Chris Velevitch)
Subject: Newton Development
Date: 16 Oct 92 13:38:12 GMT
Organization: RUNX Un*x Timeshare.  Sydney, Australia.


I want to develop applications for the Newton, but I would like
more information on what is involved.

What is the development language/environment?
What are the Design and interface guidelines?
What type of non-volatile storage and capacity?


Chris

- --
Chris Velevitch, Soft, Inc.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Howard Berkey)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Date: Sat, 17 Oct 1992 02:53:38 GMT

In article <[e-mail]> [e-mail] (Chris Velevitch) writes:
>
>I want to develop applications for the Newton, but I would like
>more information on what is involved.
>
>What is the development language/environment?
>What are the Design and interface guidelines?
>What type of non-volatile storage and capacity?
>
>
>Chris

Check comp.sys.vaporware and comp.get.competitors.to.spend.big.RandD.bucks
:-)

- -Howard
- --
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                        [e-mail]
Do what keeps thou from wilting shall be the loophole in the law.



+++++++++++++++++++++++++++

From: [e-mail]
Organization: 4th Dimension BBS
Date: Sun, 25 Oct 1992 19:03:16 EST

> I want to develop applications for the Newton, but I would like
> more information on what is involved.
>
> What is the development language/environment?
> What are the Design and interface guidelines?
> What type of non-volatile storage and capacity?
>
>
> Chris
>
> --
> Chris Velevitch, Soft, Inc.
> [e-mail]

If you believe that Dylan is the language in which you'll be developing Newton
apps (I've seen conflicting stories in MacWeek, but most of them cite Dylan as
Newton's "native" language), then you can get a start by learning about Dylan.

There is a mailing list for Dylan: [e-mail], requests
for subscription should be addressed to [e-mail].
Because of the high volume of traffic on this mailing list, there is a move
afoot to start a Dylan newsgroup.

You can also get a copy of the Dylan language manual by writing to Apple
Computer, 1 Main St., Cambridge, MA 02142 USA, or by calling them at
617-374-5300.

Dave

********************************************************************
System: fourd.com                                Phone: [phone]
Cute quote:  Being a computer means never having to say you're sorry
********************************************************************


---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Watch out for QDError
Date: 25 Oct 92 20:10:43 GMT
Organization: Kalamazoo College

This is a "don't do the same stupid thing I did" article.  I put a
call to _QDError in a program that would be used on Classic
QuickDraw machines.  "Hey, I'm publishing this source code," I
thought, "I'll be a good doobie and check for all possible
errors."  That innocuous-looking trap is, I believe, for Color QD
machines only.  Oh, by the way, it works fine on a System 7 SE,
so make that Color-QD-or-System-7 machines.

However (and this may be a bug in the system)--when running
System 6 on a Plus, it looks like a call to QDError works
_except_ that it tries to write a long where a short belongs.
This produced a pretty spectacular and hard-to-find crash.  It
just happened to overwrite the hi word of my A6 link with
zero--and the program went on to do lots of computation, and even
RTS'd OK, but the parent function had a screwed-up A6 after that.
Bad news.

Might anyone know whether this is a bug in the system?  Or is it
getting some other trap instead of _QDError, that fortuitously
just happens not to blow up the computer?

In any event--don't call QDError() unless you're running Color
QuickDraw.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 26 Oct 92 00:54:39 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Jamie R. McCarthy) wrote:
>
> This is a "don't do the same stupid thing I did" article.  I put a
> call to _QDError in a program that would be used on Classic
> QuickDraw machines.  "Hey, I'm publishing this source code," I
> thought, "I'll be a good doobie and check for all possible
> errors."  That innocuous-looking trap is, I believe, for Color QD
> machines only.  Oh, by the way, it works fine on a System 7 SE,
> so make that Color-QD-or-System-7 machines.
>
> However (and this may be a bug in the system)--when running
> System 6 on a Plus, it looks like a call to QDError works
> _except_ that it tries to write a long where a short belongs.
> This produced a pretty spectacular and hard-to-find crash.  It
> just happened to overwrite the hi word of my A6 link with
> zero--and the program went on to do lots of computation, and even
> RTS'd OK, but the parent function had a screwed-up A6 after that.
> Bad news.
>
> Might anyone know whether this is a bug in the system?  Or is it
> getting some other trap instead of _QDError, that fortuitously
> just happens not to blow up the computer?

I think that calls to _QDError (trap AA40) wrap around and end up going to
_FixToLong (trap A840) on Macs with the smaller toolbox trap table. This
should be true of any trap number above A9FF on such Macs. It's because of
this wraparound that the published TrapAvailable routines check the size of
the trap table.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

---------------------------

From: [e-mail] (Jess M Holle)
Subject: MPW C++ 3.1, does it work with MPW 3.2??
Date: 23 Oct 92 18:21:08 GMT
Organization: Purdue University Engineering Computer Network

I have MPW 3.2 shell, C compiler, the corresponding version of SADE,
etc. available to me AND MPW C++ 3.1.  Will this combination work??
What changed from MPW C++ 3.1 to MPW C++ 3.2?

Thanks,
Jess Holle

P.S.  I used to be up to date on all of the MPW stuff, but since using
Think C for all of my work for a while, I don't really remember much about
MPW and its various version details.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- ---Hoping for Think C++ (plus compiler warnings, plus backgroundable
                         compiles, plus...)
- ---Hoping for a compact, fast, easy-to-use, affordably-upgradeable MPW
- ---I will not despair, I will not despair,... (or so I keep telling myself)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Oct 92 06:44:43 GMT
Organization: Apple

In article <[e-mail]>,
[e-mail] (Jess M Holle) wrote:
>
> I have MPW 3.2 shell, C compiler, the corresponding version of SADE,
> etc. available to me AND MPW C++ 3.1.  Will this combination work??
> What changed from MPW C++ 3.1 to MPW C++ 3.2?

Well, it's officially unsupported, but that does not mean that it
does not work. As I know MPW C++ 3.1 works fine with MPW 3.2. The
biggest delta between C++ 3.1 and 3.2 is that 3.1 was based on
Cfront 2.0, while MPW C++ 3.2 is based on Cfront 2.1. In addition
we fixed Apple extension bugs. Note that MacApp 3.0(.1) is tested
and verified using MPW C++ 3.2, so you might have sporadic and unknown
problems with MPW C++ 3.1.

Kent
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

---------------------------

From: [e-mail] (Kim Kempf)
Subject: PBResolveFileIDRef() trouble
Date: 23 Oct 92 19:42:34 GMT
Organization: Acme Hitech Systems, Inc., Johnston, Ia.

I have a file ID and volume reference number.  I need to take this file ID
and (if found) get the parent directory and name.  PBResolveFileIDRef()
seems to be the likely function to use.  I know I'm setting up something
wrong because it always returns either -35 (nsvErr) or -1300 (fidNotFoundErr).
Does anyone have an example code segment that uses this function correctly?
Thanks in advance.

Think C 5.0:

#include <stdio.h>
#include <Files.h>

Str255 temp;

main()
{
    HParamBlockRec hpb;
    OSErr err;

    hbp.fidParam.ioNameptr = temp;
    hbp.fidParam.ioFileID = 676;       // this file ID is known to exist
    hbp.filParam.ioVRefNum = -1;       // assume boot volume (maybe wrong?)

    if ((err = PBResolveFileIDRef(&hpb, FALSE)) == noErr)
        printf("Filename = '%#s'\n", hpb.fidParam.ioNamePtr);
    else printf("%d\n", err);

    exit(0);
}

- --
- ----------------
Kim Kempf, Acme Hitech Systems, Inc.          uunet!mcrware!acmehi!kim
Johnston, IA 50131-1551
Tel/Fax: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, software saboteur)
Date: Mon, 26 Oct 1992 17:05:51 GMT
Organization: MacDTS Marauders

In article <[e-mail]>, [e-mail] (Kim Kempf) wrote:
>
> I have a file ID and volume reference number.  I need to take this file ID
> and (if found) get the parent directory and name.  PBResolveFileIDRef()
> seems to be the likely function to use.  I know I'm setting up something
> wrong because it always returns either -35 (nsvErr) or -1300 (fidNotFoundErr).
> Does anyone have an example code segment that uses this function correctly?
> Thanks in advance.
>
> Think C 5.0:
>
> #include <stdio.h>
> #include <Files.h>
>
> Str255 temp;
>
> main()
> {
>     HParamBlockRec hpb;
>     OSErr err;
>
>     hbp.fidParam.ioNameptr = temp;
>     hbp.fidParam.ioFileID = 676;       // this file ID is known to exist
>     hbp.filParam.ioVRefNum = -1;       // assume boot volume (maybe wrong?)
>
>     if ((err = PBResolveFileIDRef(&hpb, FALSE)) == noErr)
>         printf("Filename = '%#s'\n", hpb.fidParam.ioNamePtr);
>     else printf("%d\n", err);
>
>     exit(0);
> }

The PBResolveFileIDRef function takes the ioNamePtr field as an input
giving the name of the volume you want to look in.  To make sure you're
not confusing it, you should set that string to a null string before
calling the routine, or give it a real volume name.  Try this:

OSErr
MakeFSSpecFromFileID(short vRefNum,long fileID,FSSpec *fsp)
{   OSErr               err;
    HParamBlockRec      hpb;
    char                name[32];

    // Specify file by vRefNum + file ID; this requires ioNamePtr to be NIL
or
    //  point to a non-volume name (the empty string is safest).

    name[0] = '\0';     // Zero out name

    hpb.fidParam.ioNamePtr = (StringPtr)name;
    hpb.fidParam.ioVRefNum = vRefNum;
    hpb.fidParam.ioFileID = fileID;

    err = PBResolveFileIDSync(&hpb);
    if (err)
        return err;

    err = FSMakeFSSpec(vRefNum,hpb.fidParam.ioSrcDirID,
                         (StringPtr) name,fsp);

    return err;
}

** Note: this is sort of off of the top of my head; I'm pretty sure it
works, but I'm not certain.

Tim Dierks
MacDTS is only skin deep, but geek goes straight to the bone.

---------------------------

From: [e-mail] (Rich Siegel)
Subject: Help! CTB's NuLookup() call crashing...
Date: 27 Oct 92 18:36:37 GMT
Organization: GCC Technologies

I'm trying to use the NuLookup() routine for choosing LaserWriters on
the net. Sometimes it works, but usually it just crashes with an illegal
instruction exception, because somewhere deep inside the CTB, someone
is jumping to location zero.

Here's the setup and the call:

        NBPReply reply;
        NLType types;

        OSErr result;

        Point pt = {90, 90};

        types[0].hIcon = GetResource('SICN', 128);
        CopyStr("\pLaserWriter", types[0].typeStr);

        if (NuLookup(pt, "\pAvailable Printers:", 1, types, nil, nil, nil, &rep)
                return userCanceledErr;

Am I doing something egregiously ignorant, or is there something subtle I
need to do to get this to work?

As a side issue, how do I center the NuLookup dialog? Passing
{0, 0} or {-1, -1} doesn't work - the dialog gets stuffed in the upper
left corner of the screen - and the dialog ID of the dialog isn't
published...

Thanks in advance for any assistance.

R.

- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Leonard Rosenthol)
Date: 28 Oct 92 00:50:47 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <[e-mail]> [e-mail] (Rich Siegel) writes:
>I'm trying to use the NuLookup() routine for choosing LaserWriters on
>the net. Sometimes it works, but usually it just crashes with an illegal
>instruction exception, because somewhere deep inside the CTB, someone
>is jumping to location zero.
>
    Welcome to the most common bug in using NuLookup!

>Here's the setup and the call:
>
>        NBPReply reply;
>        NLType types;
>
>        Point pt = {90, 90};
>
>        if (NuLookup(pt, "\pAvailable Printers:", 1, types, nil, nil, nil, &rep)
>Am I doing something egregiously ignorant, or is there something subtle I
>need to do to get this to work?
>
    You are NOT initializing the NBPReply record.  NuLookup uses the
contents of the NBPReply to allow you to "prechoose" an entry to be hilited
when the dialog comes up.  However, it doesn't sanity check and the
"preflighting" feature is not documented.

>As a side issue, how do I center the NuLookup dialog? Passing
>{0, 0} or {-1, -1} doesn't work - the dialog gets stuffed in the upper
>left corner of the screen - and the dialog ID of the dialog isn't
>published...
>
    You don't :(.  You either have to use NuPLookup and attempt to center
during the init call of the filterProc or guess...


- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

---------------------------

End of C.S.M.P. Digest
**********************